vskfandomcom-20200214-history
Forum:Semantic data for this wiki
dd This discussion was started at Category talk:Tracks but this forum location is probably the better place for it to continue.;First draft: najevi 11:00, 12 July 2009 (UTC);Last update: najevi 03:57, 15 August 2009 (UTC) Overview Two collapsible sections. Look for the more / less links at right. For the benefit of SMW/SF helpers ... or anyone else not familiar with the VSK game or its jargon. '' Virtual Skipper is a sailing simulator allowing multiple players to sail the same boat design around a race course. The results of each race are dumped to a file in a CSV format. The same file is created on every participating skipper's PC. Typical fleet sizes are between 5 and 30 boats. A typical race might last 20-30 min but much longer (and shorter) races are not uncommon. Races are hosted by regular users over a peer-to-peer network using UDP (default) or TCP (fall back). *Each player may customized the appearance of their boat however, it's performance parameters ''do not change with these so-called "boat skins". There may be several tens to a few hundred skins per boat model. Some boat models being more popular than others. *Boat models are shared but they are not customized by the community. About 25-35 boat models have been created by the community so far. It seems that between 5 and 10 new boat models are created each year. *For any given race the host chooses a race course (a Track), decides which Boat (model) will race and then selects various environment conditions for the race: weather, wind, waves, time of day (hence tidal currents) and so on and so forth as well as some modes of game play. *The race tracks are designed by the player community and can be shared among the community and further customized in the same way that boat skins can be shared and customized. Tracks are more likely to be customized than boat models. There must be a few thousand race tracks created/customized by the community. These are much more prolific than either skins or boats. * The most prolific "object" is the race result file. At 30 minutes per race a 24x7 race server would see about 300 races per week. There are typically 5-10 race servers active although the actual extremes are more like 0-30 depending on day of week and time of day. Therefore it is not unreasonable to expect between 1500 and 3000 race result files generated each week. Of these maybe 5-10% might be uploaded. Of course the easier this task of uploading a race result page the larger the number of such race pages will be. These race results will be contained in the Data namespace and will not count toward wiki "content". Only the race host may upload a race result file. Raison d'etre The motivation for having various data (even some obscure data or trivia) query-able at this wiki is to enhance the after-game experience of the wider Virtual Skipper community. Some dedicated clubs and individuals have developed sophisticated web sites and spread sheets for scoring boats in a series of races comprising an event spread out over a few days to a few weeks. (e.g. http://www.vsk-match.com/ http://www.vskfun.com/ and http://www.vskmonaco.com/ - the latter is using the Ranking and Rating system developed by Theeuwes de Jong * What the is striving for is a broader scope than merely scoring a series of races for the purpose of determining the traditional winners, ranking and so forth. So long as all "naturally occurring data" about a publicly hosted race is uploaded to a Race page at this wiki then the variety of possible lists that can be generated via semantic queries run against that database is limited only by the imagination of the community members. :Casual skippers and newcomers to the game may never be earning "fastest time for a course" or "gold/silver/bronze ranking in an organized event" but they may well discover a niche set of weather conditions or a type of track on which they appear to perform especially well. Consider, for example, the newcomer seeking out Arcade mode races and wanting to see how well they performed in just that type of race. At the other extreme are the Simulation mode fans. :This ability to discover your forte/strength is great for morale ... even if it is really nothing more than trivia. It's still entertaining and it attracts people to and keeps people engaged with the game. Like-minded skippers who enjoy Manual Protest races can use queries to locate hosts who make a habit of (or who exclusively) host this type of race. The same could be said for: * NPC races * or races permitting only transparent sails * or races in Force 7 wind * or a fleet size of greater than 15 boats * ... or whatever tickles your fancy! As the database grows in size even more creative and specific queries may help designers of race courses to design Track.Gbx files that attract a specific target audience. So rather than thinking of different-minded factions among the VSK community as interfering with one another person's enjoyment of the game, any community member can use powerful semantic queries to seek out other like-minded skippers and possibly host and score events that focus on a particular style of game play. Other examples might cater to unconventional or non-traditional interpretations of the sport. e.g. play styles that: * reward pen-hunters * reward navigators * challenge skippers on wacky courses with high tidal streams, whirlpools, doldrums, shoal water etc. * the list can be as long or short as your imagination ;As a final example : I wonder how many skippers even know that a kite surfer model exists for this game? Then, among those of you who said, "Sure, I knew about that." I wonder how many of you could name 5 other skippers who have hosted or raced the kite surfer model on more than 5 occasions? :* Now, if a kite surfer (or wind surfer or whatever) fan browsing the comes across a list of race results for that particular boat model then they can very quickly identify which skippers have shown an interest in that model in the past (as either competitor or host) and this may revitalize that "faction" of the community. Team Nadeo may even discover patterns or trends in the community's habits of game play or in the demographics of the playing audience that ends up helping the company to tap into a market that they were not previously aware of. Semantic properties * (Priority) Property name DATA TYPE enumerated values mandatory *# Fields from DATA TYPE to end of line pertain to the semantic data at this wiki while fields to the left of that pertain to a discussion of data that might be automatically generated by the game client after creating a Track and/or after the last boat finishes a race. *# For DATA TYPE an asterisk (*''') indicates re-use of a previously defined property name. *# (Priority) = (A), (B), ©, etc. Also (0) & (M) These refer to a prioritized list of data that will be submitted to Nadeo for possibly including in certain plain ASCII files or file headers automatically generated by the game client. *#* (0) = this data is already provided in an easily parsed format *#* (M) = this data can be obtained manually Boat It is expected that boat data will be manually entered using a form page. There are between 25 and 35 boat models so this is not a huge task. All boat articles belong to the category: '''Boats. These will be saved in the Main namespace. "pagename" = name of boat model * Credits STRING mandatory * File size (MB) NUMBER mandatory * Download URL URL mandatory * Compatible game NUMBER allows value:: 1 - vsk1, 2 - vsk2, 3 - vsk3, 4 - vsk4, 4.5 - 32ac, 5 - vsk5 mandatory * Brief description STRING * Image gallery PAGE field|autocomplete on namespace = File ; Sail parameters (TWS) * Sail1 TWS min (knots) NUMBER * Sail1 TWS nom (knots) NUMBER * Sail2 TWS nom (knots) NUMBER mandatory * Sail2 TWS max (knots) NUMBER * Sail3 TWS nom (knots) NUMBER * Sail3 TWS max (knots) NUMBER * Sail4 TWS nom (knots) NUMBER mandatory * Sail4 TWS max (knots) NUMBER ; Sail parameters (TWA at the nominal TWS above) * Sail1 TWA min (degrees) NUMBER * Sail1 TWA opt (degrees) NUMBER * Sail2 TWA min (degrees) NUMBER mandatory * Sail2 TWA opt (degrees) NUMBER mandatory * Sail3 TWA min (degrees) NUMBER * Sail3 TWA opt (degrees) NUMBER * Sail4 TWA min (degrees) NUMBER mandatory * Sail4 TWA opn (degrees) NUMBER * Sail4 TWA opt (degrees) NUMBER mandatory * Sail4 TWA opx (degrees) NUMBER ; Sail parameters (time to change) * Sail1 change (seconds) NUMBER * Sail2 change (seconds) NUMBER mandatory * Sail3 change (seconds) NUMBER * Sail4 change (seconds) NUMBER mandatory ; Sail parameters (explain when manual trim outperforms auto or when heel is a better guide than TWA, etc,) * Sail1 comment STRING * Sail2 comment STRING * Sail3 comment STRING * Sail4 comment STRING Skin It is expected that skin data will be manually entered using a form page. There could be several 10's or a hundred skins per boat models so this would be a huge task for an individual so only community members motivated to share a skin will contribute. All skin articles belong to the category: Skins. These will be saved in the Main namespace and it is likely that heavy use of for page disambiguation will be necessary. Each skin must specify a compatible boat and that boat page must exist before a skin page for the boat is created. This is primarily to encourage contribution of boat articles. "pagename" = name of skin * Credits *''' mandatory * File size (MB) '''* mandatory * Download URL *''' mandatory * Compatible boat '''PAGE mandatory * Compatible game *''' * Sail transparency '''NUMBER allows value:: 0 - Opaque, 1 - Translucent, 2 - Transparent mandatory * (dropped) Has locator file BOOLEAN * Locator URL URL * Brief description *''' * Image gallery '''* Track Initially, track data will be manually entered using a form page. This may require that fewer fields be specified as mandatory. If the .Gbx file format can be reverse engineered then a tool to extract more of this data from those files might emerge in which case more fields will be made mandatory. (Update: such a tool is '''unlikely.' More likely, is persuading Nadeo to dump an ASCII file of Track related data for each Track.Gbx file or perhaps including that same track data in an enhanced version of the Result.csv file. ''The '''ideal solution' would be for Nadeo to agree to write this data into a clearly delimited file header within each Track.Gbx file.)'' * All track articles belong to the category: Tracks. * These will be saved in the Main namespace. * We can expect several hundred to maybe a few thousand track articles. *: Therefore, an automated way of extracting the necessary data to fully populate a track description page is highly desirable. When thinking about what weather/environmental data to use when populating a Track page, focus on the conditions at each mark on the course rather than along the leg between marks. So if the maximum wave intensity is called for then simply inspect the wave intensity at each mark on the course and report the maximum value. :Same for tidal stream'. (Remember to sample this for each of the 8 wave direction maps and go with the maximum if there is a variation among them.) :Same for wind strength. (Remember to sample this for each of the 8 wind direction maps and go with the maximum if there is a variation among them.) :Max tidal stream/current is a little different since that is affected by time of day. For that reason four pieces of data are asked for. In all fairness, the return on investment for manually inspecting, recording and then entering this weather/environmental data into the wiki is probably very poor. For this aspect of the wiki query-able data base to truly succeed will require automatic parsing/dumping of such data for each Track.Gbx file. "pagename" = name of track * (A) Author (last author) STRING mandatory (this is the "by Name" which appears in chat when a track is loaded and the folder name assigned when a track is downloaded from within an online race.) * (A) Wind shift angle (degrees) NUMBER * (A) Wind shift duration (seconds) NUMBER * (A) High tide (HHMM) DATE mandatory * (A) Venue PAGE allows value:: Vancouver, San Francisco, Tropical, Rio De Janeiro, Isle of Wight, La Trinite, Valencia, Nordic, Marseille, Porto Cervo, Napoli, Trapani, QingDao, Malmo, Sydney, Auckland mandatory ** Venue latitude longitude GEOGRAPHIC COORDINATE allows value:: * (A) Mark coordinates (array) STRING Pixel coordinates per each venue's master map (22400x16800px). ** Map view (constructed using coordinates overlay on GoogleMaps style tiled view of relevant portion of venue map) ** Distance total (Nm) NUMBER (a.k.a. Length) mandatory ** Nominal duration (minutes) NUMBER mandatory ** Distance first leg (Nm) NUMBER ** Number of mark (roundings) NUMBER this could be derived from a "Next-Gen" Result.csv file if an array of posn[] and time[] is recorded for each participant ** Number of gates NUMBER * (B) Maximum wave intensity (%) NUMBER * (B) Max high tide current (knots) NUMBER * (B) Max ebb tide current (knots) NUMBER * (B) Max low tide current (knots) NUMBER * (B) Max flood tide current (knots) NUMBER * © Number of spawn points NUMBER (probably not as important as Max Players (see Race section) * (M) Credits (original author(s) ) STRING (manually entered only if this is a derivative work) * (M) Skippers Brief TEXT (manually entered. Local knowledge about course that would be shared at a skipper's briefing.) * (M) Has these obstacles STRING allows value:: land, small vessel traffic, large vessel traffic, anchored vessel, shoaling water, intense local stream, local wind shadow, civil works ;Mark coordinates suggestion ;# Consistently use 2 coordinate pairs per mark (i.e. necessary to handle start line, finish line and gates). ;# For port/starboard rounding marks let the first pair specify location of the buoy while the second pair specifies port/starboard rounding. e.g. port=(-MaxInt,-Maxint) & starboard=(-Maxint,Maxint) If coordinates are guaranteed >=0 then let port = (-1,-1) and starboard=(-1,1). ;# Repeat identical coordinates if a mark is reused on a subsequent leg but always use the second coordinate pair to specify port/starboard rounding. Race None of the following data is expected to be entered manually. We can expect thousands of race pages so 2 or 3 click upload of this data must be realized or this aspect of the wiki will not succeed. Whilst some of these parameters are chosen by a host when setting up a race server it is not practical to expect either race results or race condition data to be entered manually. At the present time the only race data that we can count on seeing uploaded is indicated with an asterisk (*) below. It is hoped that at least the Host, Track and Boat names can soon be added to this short list. (See Next-gen Result.CSV file below.) "pagename" = uniquely identifies race (e.g. date-time-stamp of start & finish plus host name) ; Host determines the following * (A) Host name PAGE field|autocomplete on category = Hosts mandatory * (A) Track.Gbx file name STRING * (A) Track.Gbx checksum STRING ** Track PAGE field|autocomplete on category = Tracks mandatory * (A) Boat.Zip file name STRING * (A) Boat.Zip checksum STRING ** Boat PAGE field|autocomplete on category = Boats mandatory * (A) Time of starting gun (Virtual) DATE (coupled with '''High tide' (DATE) from the Track.Gbx file this establishes the tidal stream conditions for a race'') * (A) Pre-start duration NUMBER * (A) Last restart time (Zulu/UTC) DATE *: This should be derived from the Host's local time but adjusted to UTC based on the Host's time zone. All participants should have a Result.csv file named with an identical Result_YYYY_MM_DD_HH_MM_SS.csv date-time-stamp. (This is '''not' the current situation.) ** Start time (Zulu/UTC) '''DATE' * (A) Weather NUMBER allows value:: 0 - Sunny, 1 - Cloudy, 2 - Rainy, 3 - Stormy * (A) Wind direction NUMBER allows value:: 0 - North, 45 - NE, 90 - East, 135 - SE, 180 - South, 225 - SW, 270 - West, 315 - NW * (A) Wind strength (Beaufort scale) NUMBER allows value:: 3 - 7..10kn, 4 - 11..15kn, 5 - 16..20kn, 6 - 21..26kn, 7 - 27..33kn * (A) Wind shifts NUMBER allows value:: 0 - None, 1 - Stable, 2 - Oscillating, 3 - Shifty, 4 - Unstable * (A) Race mode NUMBER allows value:: 0 - Fleet, 1 - Match, 2 - Team (a.k.a. Game type) * (A) Game mode NUMBER allows value:: 0 - Arcade, 1 - Tactical, 2 - Simulation * (A) Rules mode NUMBER allows value:: 0 - Without, 1 - Complete (Auto), 2 - Complete (Manual) * © Max players NUMBER * © Game client build/minor version STRING ** Game version NUMBER allows value:: 1 - vsk1, 2 - vsk2, 3 - vsk3, 4 - vsk4, 4.5 - 32ac, 5 - vsk5, 6 - vsk6 mandatory ; Each participant in race "determines" the following * (A) Team color at finish NUMBER allows value:: 0 - neither(spec), 1 - Red, 2 - Blue * (B) Elapsed time at each mark (array) STRING time0=start, time1=mark1, ... timeN=finish *: If a skipper retires or is disconnected then in the Result.csv file seen by all remaining skippers the time of departure should be recorded as an elapsed time assigned to the mark that the departing skipper never rounded. Of course the status flag for the departed skipper becomes DNF if racing. A departing skipper who had been in spectator mode since the last restart will have the time of departure reported against time0 i.e. the starting line since that is the earliest mark that the spectator mode skipper never "rounded". * (B) Position at each mark (array) STRING posn0=start, posn1=mark1, ... posnN=finish ** (0) posnN i.e. a participant's finishing place ** (0) timeN i.e. a participant's elapsed time at finish * (0) Skipper login name STRING the login name used to authenticate when playing online * (0) Skipper nickname/alias STRING including any $-codes for colored, rich text nicknames * (0) Status flag STRING allows value:: SPEC, DNC, DNS, DSQ, DNF, FINISHED * © Ladder points gained/lost NUMBER * (M) Points awarded NUMBER ;Questions : Should any skipper who comes and goes as a spectator be recorded in the results file? : If not then should the SPEC flag only apply to a skipper who remained in spectator mode for the entire duration from last restart to last boat finishing? : I assume a skipper who goes from race mode to to spectator mode before the start gun is recorded as DNS, correct? : Team colors can be changed during the course of a race. Should the team color at each mark rounding be recorded? (If team colors can be changed in the course of a race, that would be a bug. AFAIK at present it can be changed only until the prestart gun. --Admiral 1 07:06, 17 August 2009 (UTC)) Examples of information that can be derived from the above data ''' * Finish time (Zulu) '''DATE (perhaps of interest to any skipper who needed to leave a memorable race before finishing) * Finish time (Virtual) DATE (easily derived if Start time (Virtual) is provided) * Fastest 1st leg (mS) NUMBER (this rather progressive idea is definitely worth pursuing if Nadeo is willing/able to '''come to the party) * Fastest elapsed time (mS) '''NUMBER * Number of DNS boats NUMBER * Number of DNF boats NUMBER * Number of DSQ boats NUMBER * Number of finishing boats NUMBER ;Dedicated namespace All race pages will belong to the category: Races. These will be created in the custom namespace Data: and not the Main: or Project: namespaces. Pages in the Data: namespace * will not be selected by the Special:RandomPage tool * will not appear in results list from the wiki site search * are not intended to be browsed or read by the typical visitor * are intended to be the subject of semantic queries Automated upload mechanism The tentative plan is for the above data to be automatically extracted from the Result.CSV file. (The '''Autosave.Replay.Gbx' does not look like it is going to yield enough useful data to warrant spending time and energy to figure out how to reliably parse it.) The Result.CSV file will be parsed by some java/C/lua script and a single XML file created in a format suitable for import into the wiki using (''probably not) or the Semantic Forms extension (currently the most likely). * FYI: For users with import permissions, multiple wiki pages (e.g. 100's at a time) can be created (or changed) in just one XML file upload. This is an awesome utility but it also presents some security risk. If abused it could result in devastating vandalism that is much more tedious to recover from than traditional "incremental" vandalism which is truly easy to recover from. It ultimately boils down to ... '''trust' & risk management.'' Precise details are not yet clear to me however, I am currently thinking that only the host of a race may upload a Result.CSV file for that race. This will completely sidestep a number of potential problems due to partial result files uploaded by skippers who may not have stayed until the end of the race, for whatever reasons. Only the host is guaranteed to have stayed for the full duration - whether racing or spectating. * The ideal situation is that the host of a race use the same nickname for Wikia login as they currently use when authenticating to play VSK5 online. The upload process can then easily check for that condition and treat race results uploaded by the race host as the definitive set of results. ** It won't be too hard to accommodate a different nickname for VSK login and Wikia login - perhaps those will simply be stored in a config.ini file for the script.. A post-processor script will be distributed as source code, not binary. Any user can use this script to parse all Result.CSV files in the directory: ( %USERPROFILE%\My Documents\'Vsk5'\Results .. | 32nd America's Cup | Vsk5Online ). The user will specify the login name they use for VSK authentication online and the script will match that name to the login name of the host. When a match is successful the post-processor will prepare that Result.CSV file for upload to the wiki. *For this to work the name of the host must either be *# part of the Result.CSV filename or *# easily identifed within the Result.CSV file contents (something as simple as a #-character prefix to the host-name in the second column of race results is sufficient) This will completely avoid the need for complex logic at the time of upload to the wiki and it will reduce the time wiki contributors spend uploading Result.CSV files since there will be no duplication of effort. Of course if a host suffers a loss of data or is simply not a willing contributor to the then those race results cannot be queried unless the host recovers the lost data or decides to contribute. * This is why the upload process must be fully automated. Maybe a few mouse clicks to upload data from a week's or a month's worth of hosted races. Next-gen Result.CSV file When told about these ideas for loading race results into a powerful, query-capable database, Nadeo representative, Florent (a.k.a. Hylis), asked to see my wish list for additional data to be written to the Result.CSV file. A prioritized version of the above list was provided in the last week of July 2009. I sincerely hope that Nadeo agree to supplement the already comprehensive race results data in that file with * race conditions data * identification data for: host, track and boat ;Nadeo delivers : read this description of the new result.xml file to see the extent to which Nadeo have managed to cater to this request. :-- najevi 04:24, November 9, 2010 (UTC) MISSING FEATURES 1. Host = login name of race host (maybe within tag) 2. Team = red, blue (maybe within tag) NEW SCHEMA (closing tags not shown) date in UTC time of the start of the race date in UTC time of the end of the race indicates the boat model used during the race type of race = 'Fleet Race', 'Match Race', 'Team Race' rules mode = 'None', 'Auto', 'Manual' ('Auto' or 'Manual' indicating complete rules used). duration of the pre-start = 'Immediate', '1 min', '3 min', '5 min', '8 min' game mode used during the race = 'Arcade', 'Tactical', 'Simulation'. virtual time of the race start the tide period corresponding to the start of the race = 'Low', 'Flood', 'High', 'Ebb'. weather setting of the race : 'Sunny', 'Cloudy', 'Rainy', 'Stormy' the prevailing wind direction the force of wind wind-shift setting = , , , , . contains one tag block for each player involved in the race. race time in milliseconds of this player or 'DNC', 'DNS' or 'DNF' Although each Race page must specify a Track page the track page does not need to have been created in advance. Indeed one feature of Semantic Forms extension is the automatic creation of a place holder page when a non-existing page is referenced. Of course data about the track will need to be added manually unless the key pieces of data are also written to the Results.CSV file. Race page names must uniquely identify any given race and will therefore be formed as: *':'. e.g. daemon9:2009_08_03_19_41_47 The average wiki visitor is not going to browse race articles however the average visitor will enjoy powerful data base queries that return such lists as # top 10 elapsed times for specified weather conditions # most popular tracks # longest races # largest fleet for a specified track # relationship between weather conditions and number of DNFs # and so on and so forth These queries are easy to construct once the data has been annotated using the Semantic MediaWiki extension. There is virtually no limit to the creativity (or obscurity) of possible queries. Newly created queries can be saved and those queries can be added to a list of favorite pages so each user can rather easily customize there user-page (or a sub-page) to deliver a swathe of query results each time they visit the wiki! File formats Three files promise to be useful. # Result_YYYY_MM_DD_HH_MM_SS.csv # MultiPlayerAutoSave##.Replay.Gbx # .Gbx The Trackmania wiki has documented some of the Gbx file format used for that title - also developed by Nadeo. That information may prove helpful here. It has not yet been applied here. A disassembler library looks promising. Race results ; Result_YYYY_MM_DD_HH_MM_SS.csv 1,1844631,najevi,$c93najevi 2,1846785,the_blokarter,$i$s$ff0 uk $00f kiwi 3,1852858,dani_vito,Chipironet 4,1853787,arcibaldo,$w$i$33c DhM $m$i$0f0 (v$fffsk$f03a) 5,DNF,chiqui_iv,chiqui_iv 6,DNF,chrispalmieri,sailpalms 7,DNF,pierreduchesne39,$00fPI$fffER$f00RE$0f039 8,DNS,fmn,fmn 9,-1,daemon9,TKR : Plain ASCII comma separated variables list (4 columns): :# Finishing place :# Elapsed time in mS | DNF | DNS | DNC | -1 | :#* OCS is not possible since you cannot finish a race with a pen 30.1 - you are forced to go spec or be kicked and your result file is never created but others who do finish the race see your result as DNS. :# Login name (best identifies a user) :# Nickname (other skippers will remember seeing this label on a boat and not a login name) Prefered format of existing data :# position :# flag DNS,DSQ,DNF,-1 (We need a flag for a boat that finishes. I suggest: 0.) :# time (also with flag, then exit time. Allows redress and also equals can be avoided where appropriate) :# points :# login name :# nickname (stripped from color codes) :# team |blue (appended 7th column to participants result where race type = team) (instead of above would allow for simple edit to allow for manual protests, appeals, redress, especially where results are not processed through a parser. Aka load .csv in spreadsheet.) --Admiral 1 19:55, 11 August 2009 (UTC) I very much agree Admiral. Adding team color and also time of exit from the race is key. (Have you thought about what time reference the elapsed time should be for a DNS boat?) Elapsed time for DSQ,RET,DNF etc. etc. This is only of value in races where time is basis for anykind of evaluation, across races. (As alternative to Points) What seams to be fair is that none finished boats are awarded a finishtime in accordance with their position. Calculated from the average time of the other boats. The average of all deltas to 1st finhstime added to the time of the last finished boat. I dont think a debate about the correctness of that solution is at place now.. and should be left to the user/parser unless Nadeo themselfes want to evaluate time across races. An exit time imo can help determining chronology, after ordering on severity of flags. ) --Admiral 1 11:16, 14 August 2009 (UTC) I would not recommend stripping $-codes from the nickname. A post-processor could do this easily enough if the target database cannot use the $-codes. Even though I am not a fan of the Rich-text nicknames, I suspect that many users find these easier to remember as rich text and so would appreciate being able to look for and recognize a properly reconstructed rich-text boat nickname. * It's a very low priority project for me but I can imagine an albeit complex template that parses the boat name with $-codes and produces the same Rich-text boat name (including any special characters) that we can see in-game. Actually the name IMO is only for human readability and identifying a vsk-id through the alias in the race, obviously it's no trouble loading a skipper profile through the vsk-id where then then alias, avatars, history etc can be found...--Admiral 1 11:22, 14 August 2009 (UTC) --najevi 06:48, 14 August 2009 (UTC) ; Signicantly absent : Name of host : Name of boat model : Name of track : See also Race list above ; MultiPlayerAutoSave##.Replay.Gbx This is a binary file but there are some plain ASCII portions that yield useful information: GBX : : QingDaoX : : ACC So far the obvious data is * 1st, 2nd & 3rd place elapsed time * Site * Boat model * could be other data To parse this properly may need help from Nadeo or a VSK club member whose explored this before now. Speculating (headertype = replay) * challenge uid="gcPW17r2KnSjJOmvr_luUGAc4i2" md5 of track for that race? * exever="0.2.0.4" vsk.exe version? !! Obvious the track must be part of/ inside the replay. (header type is challenge) * nblaps="0" number of laps (Trackmania relict)? * bronze, silver, gold point to the gold, silver , bonze medal times (Trackmania relict)? * uid = id of something possibly author * name = Name of the challenge. * author = name of the author (saved track) --Admiral 1 20:35, 11 August 2009 (UTC) Track definition ; .Gbx : These GBX files appear to be a serial data record format with only a few areas of recognizable plain ASCII data. Florent advises that the only way to properly parse the file is with the entire game client. It is therefore unlikely that any effort will be spent trying to decypher the serial data record format.